-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
frame/system/src/lib.rs
Outdated
/// # </weight> | ||
#[pallet::weight(T::SystemWeightInfo::remark_with_event(remark.len() as u32))] | ||
//#[pallet::weight(T::SystemWeightInfo::remark_with_index(remark.len() as u32))] | ||
pub fn remark_with_index( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to have this part of frame-system
?
This will bleed into any chain using Substrate, including Polkadot/Kusama.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a standalone chain, but a substrate feature indeed. @gavofyork suggested it should be enabled on kusama and eventually polkadot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but that could also be done by a special pallet.
I mean parachains will then also get this functionality etc. IMO we should not enable this by default everywhere. Yes, everybody could filter the call, but that sounds more like a hack to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I'll move it to a separate pallet.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Waiting on #10779 |
484cce7
to
de84ade
Compare
@bkchr This is ready for review again |
+ GetDispatchInfo | ||
+ From<frame_system::Call<Self>>; | ||
/// Weight information for extrinsics in this pallet. | ||
type WeightInfo: WeightInfo; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also have a
// Origin that control the ability to index a remark.
type ControlOrigin: frame_support::traits::EnsureOrigin<Self::Origin>;
but I don't think it is necessary at this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logic looks good, wonder a bit about the naming.
The PR could call system remark internally, but I don't think it is needed, and I really like this better.
Still, we use a different event, and the pallet could be named differently than pallet-remark (to avoid confusion with system remark). But really depends on the directions that the pallet may take.
One point I find interesting, is that this will only serve content as long as state is not pruned, may need to be extended.
A second point is that sp-io transaction host function are now not only for transaction; and could be renamed (as long as no non test runtime uses them), for instance 'offchain_indexed' instead of 'transaction_index', but maybe offchain is also confusing due to other existing offchain substrate functionalities.
Also been wondering if at some point an api that do not put the ipfs content in block could be interesting (would act like here but with content fetched from ipfs).
(I also added myself a TODO to implement Reference and Release for paritydb (I just realized it is missing))
This is supposed to be a new version of the
That's not correct. Nothing is saved in the state here. Remarks are stored as block bodies basically. They will be kept around unless block body pruning is enabled.
Host function names are not that important. Besides, I think the name is still relevant. |
👍 yes, I confused block pruning with state pruning while reading. |
pub fn store(origin: OriginFor<T>, remark: Vec<u8>) -> DispatchResultWithPostInfo { | ||
ensure!(!remark.is_empty(), Error::<T>::Empty); | ||
let sender = ensure_signed(origin)?; | ||
let content_hash = sp_io::hashing::blake2_256(&remark); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we use the T::Hashing
for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I have now seen it is because of the transaction indexing. But that should have maybe been generic as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hashing scheme has to match the scheme supported by the IPFS bitswap server. The generic parameter would need to be propagated to sc-network
module somehow. For not it is hardcoded to blake2
Co-authored-by: Bastian Köcher <[email protected]>
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
bot merge |
Waiting for commit status. |
* Remark storage * Fixed benches * Update frame/remark/src/lib.rs Co-authored-by: Bastian Köcher <[email protected]> * Fixed build * Fixed build Co-authored-by: Bastian Köcher <[email protected]>
* Remark storage * Fixed benches * Update frame/remark/src/lib.rs Co-authored-by: Bastian Köcher <[email protected]> * Fixed build * Fixed build Co-authored-by: Bastian Köcher <[email protected]>
* Remark storage * Fixed benches * Update frame/remark/src/lib.rs Co-authored-by: Bastian Köcher <[email protected]> * Fixed build * Fixed build Co-authored-by: Bastian Köcher <[email protected]>
This PR Implements https://github.com/paritytech/labs/issues/1
Implementation adds a new runtime function
System::remark_with_index
. Remark bodies are stored in theTRANSACTION
column, much like indexed storage chain content. Serving over IPFS is enabled with--ipfs-server